Here's some more:

1) When simulating a route with two sectors: Flying the 1st sector and the 1st sector magenta line displays in the virtual radar, but if the second sector is selected (whilst still flying the 1st) then no magenta line is displayed at all in the virtual radar. I would prefer for all sectors to be shown in the Virtual Radar whichever is the active sector, but if only one can be visible then it should always be the active sector.

2) If I create a waypoint over a town then I (quite rightly) do not have the 'land here' option available for that waypoint. However if I have a POL at an airfield waypoint I can then drag this and drop it onto a town and the POL attribute is not reset.

Thanks, that sort of feedback is useful. Behind the scenes the multiple sectors do not have to be contiguous, so we want the user interface to enforce contiguous-ness as much as possible in the normal course of adjusting routes. I'll publish another beta in a couple of days with such issues improved.

Looks really good at first glance. One small problem I've noticed is that if you delete a waypoint (right click and select remove waypoint) which is a POL (i.e. the waypoint appears in two sectors) then the waypoint is only deleted in the current sector. This can result in routes that are broken with gaps in the middle!

Edited to add trivial point: when saving route the default name uses the first and last waypoints of the current sector not the whole route.

Edited again to add: the 'remove waypoint' feature also applies if an intermediate POL is dragged to a different location.

That's exactly the sort of guesswork we don't want to be doing automatically. As it stands, most people never set an explicit takeoff time. If you have, and you split a sector, the second sector will be brand new and its takeoff time will be undefined. The ETA function is a navigation function that applies only to the selected sector, there is no special processing for multi-sector routes.

I've now posted a beta including the functionality at the link below.
http://www.skydemon.aero/start/SkyDemonBeta.msi

What will happen to the times if you plan a flight from A->B then insert a POL in the middle? Presumably the 1st sector can keep its initial takeoff time, but what about the 2nd sector if you don't have a 'time on the ground' field. You could just default to 'time on the ground' of zero so that ETA at the final destination will remain the same but this would be very inconvenient as you will then have to manually update all the subsequent sectors and repeat this every time you insert a POL into an existing sector. 

As each sector is its own flight in its own right, they all have their own flight details window entries and so all have their own takeoff time field already.

This sounds like a great idea. Another requirement may be the ability to add an ETD (Estimated Time of Departure) for each POL (which may be the next day or later for an overnight stop) so that a flight plan pre-filed for a leg further down-route would have the correct times and DOF in it.

Simon

Chris, your first main paragraph is correct by my understanding.
I've implemented this with a simple "Land Here" command on the context menu for a turning point which inserts a POL as you call them, but behind the scenes it splits your sector into two distinct sectors.
There is a corresponding "Do Not Land Here" command to join up the two sectors into one again.
Fuel flow is going to be the big thing to get right going forward, but I must reiterate that for the forthcoming 3.0.8 I can't do that; it will literally just be the splitting and joining parts so that multiple seconds are represented in one flightplan. After 3.0.8 goes live, assuming there are no major issues with what I've already done, we'll get cracking on intelligently flowing the fuel from one sector's model through to the next etc and being able to specify that you'll be "topping up" at a POL.

Hi Tim,
What you propose is more or less what I do now using an Excel sheet, defining landing and fuel flow... So for me it is a very good option.

That's great news, Tim! I really think you are using this forum to good advantage in developing SD further. The only other company I know which does so is Dynon.

Your proposal sounds good. The way I understand it is that in the planning stage you can define points-of-landing (POLs) which break a long route into individual sectors. What SD displays in terms of ETA (final), DST (final), NOTAMs, etc. and the portion shown in the vertical crosssection view pertains only the the currently active segment. POLs are visually distinct from other waypoints. SD essentially treats a multi-sector route as a sequence of individual single-sector routes. Everything we have known to apply to routes will henceforth apply to each sector of a route individually, right?

For sectors to be useful during planning, it would be necessary that each waypoing can easily made into a POL and back again to an ordinary waypoint. The way I would be using this feature during planning is this: on a long trip, say across the US, I would plan the entire route as one sector. Then, depending on fuel and facilities I would break it down into individual sectors by choosing POLs. Therefore it should be easy to see the effect on fuel status when choosing this or that POL. I would optimize the route and come up with a properly "sectorized" version of it. Then, during the flight, there might be circumstances which require a deviation from the plan, i.e., I am actually landing one waypoint further along because of favorable winds. Upon landing, it should then be easy to adapt the planning to the new situation. This would mean to un-POL the previously planned stop and put a POL at where I actually landed. I would then specify fuel on board for this new POL and expect to see updated fuel available figures along the route. Based on these, I would then move my POLs to a new optimum.

I hope I made this clear from a user's point of view so that a software developer can see the underlying reason behind it and maybe even improve on it.

Excited to see this new feature, -- Chris.